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(54) Mobile network system and service control information changing method 



(57) The mobile network system and the service 
control information changing method are disclosed in 
which by transmitting a registration request message 
containing change information of service content from 
the mobile terminal equipment to a foreign agent appa- 



ratus, the service control information concerning the 
mobile terminal equipment that is possessed by each of 
the foreign agent apparatus, a foreign server apparatus, 
a home server apparatus, a home agent apparatus, and 
a correspondent node is updated. 
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Description 

BACKGROUND OF THE INVENTION 

[0001] The present Invention relates to a mobile net- 
work system having an IP service control mechanism 
enabling the administration and execution of a value 
added service in unit of a terminal (subscriber) in an IP 
network system including a mobile environment and a 
service control information changing method. 
[0002] There are listed below some abbreviations for 
use in this specification, which are typically used in the 
communications field. These abbreviations are suitably 
utilized for explanation throughout this specification. 

AAA— Authentication Authorization and Accounting 
AAAF— Authentication Authorization and Account- 
ing-Foreign 

AAAH— Authentication Authorization and Account- 
ing-Home 

AVP-Attribute Value Pair 

CLI— Command Line Interface 

CN— Correspondent Node 

COPS— Common Open Policy Service 

FA— Foreign Agent 

HA— Home Agent 

HTTP— Hyper Text Transfer Protocol 

IETF— Internet Engineering Task Force 

IP-Internet Protocol 

ISP— Internet Service Provider 

MN-Mobile Node 

NAI— Network Access Identifier 

PBN— Policy-Based Networking 

RADIUS— Remote Authentication Dial In User 

Service 

RFC— Request For Comments 

SLA— Service Level Agreement 

SNMP— Simple Network Management Protocol 

SPC-Service Profile Cache 

SPDB-Service Profile Data Base 

UDP— User Datagram Protocol 
. WUI-Web User Interface 
. WWW- World Wide Web 

[0003] I n an I P network having the audio commu nica- 
tion and the data communication integrated and to 
which a wide variety of terminals are connected, the im- 
plementation of a QoS assurance is requisite in order to 
protect a delay sensitive traffic or a high priority traffic 
on the business. As a method of realizing the QoS as- 
surance, the methods Int-Serv and Diff-Serv have been 
proposed, but a Diff-Serv support with less overhead is 
most likely as the carrier network or back-bone network. 
However, the Diff-Serv needs a policy setting to the net- 
work equipment on the communication path, resulting 
in the problem that with the Diff-Serv singly the network 
administration becomes intricate. Therefore, a concept 
of the PBN (Policy-Based Networking) for collectively ef- 



fecting the policy setting to the network equipment from 
the policy server has been proposed mainly by Venda 
in the United States. 

[0004] FIG. 77 is a block diagram of the conventional 

5 network for explaining the concept of the PBN. In the 
PBN, the policy server sets an operation policy of net- 
work to a network equipment group, and the network 
equipment group refers to this set policy, thereby imple- 
menting the services with the QoS assurance. 

10 [0005] As the conventional techniques associated 
with the mobile IP, a method of employing the Mobile-IP 
in cooperation with the DIAMETER that is the AAA pro- 
tocol, and a mobile IP network as disclosed in US patent 
No. 996830024A have been well known. FIG. 78 is a 

15 block diagram of the mobile IP network as disclosed in 
US patent No. 996830024A. 
[0006] For example, with the method 
(draft-calhoun-diameter-mobileip-03.txt) of employing 
the Mobiie-IP in cooperation with the DIAMETER 

20 (draft-calhoun-diameter-1 0.txt) that is the AAA protocol, 
in an IP network where a plurality of local area networks 
are present, the Mobile-IP for supporting the location 
registration of the mobile terminal equipment and the 
transfer of IP packets destined to the mobile terminal 

25 equipment and the DIAMETER for supporting the AAA 
in the network where there are a plurality of ISPs are 
employed in cooperation, whereby the IP packet trans- 
fer to the Mobile-IP mounting terminal and the AAA were 
enabled in the environment where there are a plurality 

30 of ISPs. 

[0007] In order to effect the service control to deal with 
the mobile terminal equipment in the IP network where 
there are a plurality of ISPs, a method was disclosed in 
US patent No. 996830024A, in which the service control 

35 information is set to the HA or FA that is an edge appa- 
ratus within the network at the time of executing an initial 
location registration phase of the mobile terminal equip- 
ment in accordance with the mobile IP and the DIAME- 
TER. In particular, in order to implement a service con- 

40 trol method for individual subscribers on a plurality of 
ISP networks, the service control information is set to 
' the node on the transfer path of IP packets for the mobile 
terminal equipment in making an initial location register- 
ing procedure which is performed when the mobile ter- 

45 minal equipment is moved. 

[0008] By the way, considering the policy setting for 
each mobile terminal equipment in the PBN, it is re- 
quired that the policy may be reset for all the network 
equipment groups that can possibly accommodate the 

50 mobile terminal equipment at the time of adding or al- 
tering the policy, resulting in a problem that the policy 
setting process amount is increased over the overall 
network. Further, in order to apply the information noti- 
fied with the PBN to a fundamental service provided in- 

55 dividually such as the mobile I P, the determination of the 
specifications for application to services and the review 
for the mounting method were required. 
[0009] In particular, in a seamless global network 
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comprising various providers or carriers for supporting 
the mobile terminal equipment, all the local area net- 
works must be able to determine the policy for the user 
who has the possibility of connection and set the infor- 
mation to the network equipment. To effect this with the 5 
PBN, it is requisite that the policy information of all the 
users is carried locally, or the information is preset to all 
the network equipment having the possibility. It is very 
inefficient or unrealistic that the policy information is car- 
ried or set to about hundred million users. Also, if the 
policy information of all the users is carried in the net- 
work equipment at any time, the memory capacity of the 
network equipment is increased, resulting in reduced 
processing ability. On the contrary, in the case where a 
method of making an inquiry to the policy server at each 
time is adopted, the overhead due to the inquiry may 
occur, bringing about the risk that the SLA can not be 
followed. 

[0010] Also, the method of employing the Mobile-IP 
in cooperation with the DIAMETER that is the AAA pro- 
tocol supports a function of setting the information re- 
quired for the transfer of packets to the mobile terminal 
equipment to the FA or HA which is the edge apparatus 
within the network, but not a function of setting the serv- 
ice control information to deal with the mobile terminal 
equipment. 

[0011] In the method as disclosed in US patent No. 
996830024A, the service control information to deal with 
the mobile terminal equipment is set only when the initial 
location registration due to the movement of the mobile 
terminal equipment is effected, and the service control 
information to be set is the fixed information produced 
at the time when the mobile terminal equipment has 
made a contract with the ISP, which information can not 
be altered flexibly online upon a request from the mobile 
terminal equipment. The service control for the user is 
agreed by the user who has made a contract with the 
ISP, and fixed, and is not adaptive to a network service 
form for the user that occurs after the contract, resulting 
in a problem that any flexible measure such as utilizing 
an idle network resource upon a request from the user 
can not be taken. 

SUMMARY OF THE INVENTION 

[0012] The present invention has been achieved in 
the light of the above-mentioned problems , and it is an 
object of the invention to provide a mobile network sys- 
tem that allow the effective use of idle network resourc- 
es, and a service control information changing method. 
[001 3] The mobile network system comprises a home 
network to which the mobile terminal equipment users 
subscribe, a foreign network other than the home net- 
work, and a network management system for making 
the resource management of the whole network and 
which is connected to the home network. The home net- 
work has a home agent apparatus having a home ad- 
dress to cope with the mobile terminal equipment and 



relaying a packet transmitted from a correspondent 
node to the mobile terminal equipment, and a home 
server apparatus for managing the authentication, au- 
thorization and accounting concerning the home net- 
work. The foreign network has a foreign agent appara- 
tus for relaying the packet transferred from the home 
agent apparatus to the mobile terminal equipment, and 
a foreign server apparatus for managing the authenti- 
cation, authorization and accounting concerning the for- 
eign network. By transmitting a registration request 
message containing the service content changing infor- 
mation from the mobile terminal equipment to the for- 
eign agent apparatus, the service control information 
concerning the mobile terminal equipment which is pos- 
sessed by each of the foreign agent apparatus, the for- 
eign server apparatus, the home server apparatus, the 
home agent apparatus and the correspondent node is 
updated. Since the service control information can be 
updated by transmitting the registration request mes- 
sage from the mobile terminal equipment, the network 
resource can be effectively used upon a request from 
the user (or the mobile terminal equipment) when there 
is an idle network resource. When the registration re- 
quest message is transmitted from the mobile terminal 
equipment, the service control information of the appa- 
ratuses involving the communication between the mo- 
bile terminal equipment and the correspondent node is 
only updated. Therefore, the apparatuses to be updated 
can be suppressed to a minimum, the procedure re- 
quired for the updating process of the service control 
information can be simplified, and the costs of this up- 
dating process can be reduced. 
[0014] Also, a mobile network system of the present 
invention comprises a home network to which the mo- 
bile terminal equipment users subscribe, a foreign net- 
work other than the home network, and a network man- 
agement system for making the resource management 
of the whole network and which is connected to the 
home network. The home network has a home agent 
apparatus having a home address to cope with the mo- 
bile terminal equipment and relaying a packet transmit- 
ted from a correspondent node to the mobile terminal 
equipment, and a home server apparatus for managing 
the authentication, authorization and accounting con- 
cerning the home network. The foreign network has a 
foreign agent apparatus for relaying the packet trans- 
ferred from the home agent apparatus to the mobile ter- 
minal equipment, and a foreign server apparatus for 
managing the authentication, authorization and ac- 
counting concerning the foreign network. By making a 
request of changing the service content from the net- 
work management system to the home server appara- 
tus, the service control information concerning the mo- 
bile terminal equipment which is possessed by each of 
the foreign agent apparatus, the foreign server appara- 
tus, the home server apparatus, the home agent appa- 
ratus and the correspondent node is updated. Since the 
service control information can be updated upon a re- 
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quest from the network management system, the con- 
tents of the network resource available to the user can 
be set up in accordance with the service conditions of 
the network resource, making it possible to effectively 
use the network resource. 5 
[0015] The home server apparatus has an access 
right to a service information database for storing the 
present service content information for every mobile ter- 
minal equipment, and when the registration request 
message is transmitted from the mobile terminal equip- 10 
ment, the service content information stored in the serv- 
ice information database is desirably changed within a 
range of the service content stipulated by contract for 
the mobile terminal equipment. Since the service infor- 
mation database is changed within the range of the serv- '5 
ice content stipulated by contract, the network resourc- 
es can be effectively utilized by releasing the excess 
network resource in accordance with the practical 
amount of communication, in the case where a wide 
communication band is secured in contract but a small 20 
number of packets are actually transmitted or received. 
[0016] It is desirable that the home server apparatus 
has an access right to the service information database 
that stores the present service content information for 
every mobile terminal equipment, and when the regis- 25 
tration request message is transmitted from the mobile 
terminal equipment, make a negotiation with the net- 
work management system, if the service content infor- 
mation to be changed is outside a range of service con- 
tents stipulated by contract for the mobile terminal 30 
equipment. Since the negotiation is made between the 
home server apparatus and the network management 
system at the time of changing the service content, it is 
possible to make a change beyond the range of contract 
in accordance with the idle situation of network resourc- 35 
es, and to effectively use the whole network resources. 
[0017] The home server apparatus desirably enables 
the mobile terminal equipment to perform an initial loca- 
tion registration procedure with the aim at changing the 
service control information at a moment when the serv- 40 
ice content information stored in the service information 
database is changed. By enabling the mobile terminal 
equipment to perform the initial location registration pro- 
cedure at a moment when the service content informa- 
tion for every mobile terminal equipment which the 45 
home server apparatus carries is changed, it is possible 
to set up the service content that has appropriated the 
initial location registration procedure performed by the 
mobile terminal equipment. 

[0018] Upon receiving a predetermined message cor- 50 
responding to the initial location registration procedure, 
the server apparatus desirably updates, on the basis of 
the service content information after change that is 
stored in the service information database, the service 
control information possessed by each of the foreign 55 
agent apparatus, the foreign server apparatus, the 
home server apparatus, the home agent apparatus, and 
the correspondent node which are present on a commu- 
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nication path between the mobile terminal equipment 
and the correspondent node. Since the service control 
information of each apparatus on the communication 
path between the mobile terminal equipment and the 
correspondent node is updated in accordance with the 
initial location registration procedure performed by the 
mobile terminal equipment, the service conditions of the 
network resources can be changed suitably. 
[0019] It is desirable that the home agent apparatus 
has a list of addresses for the correspondent nodes that 
become a communication partner, and the home server 
apparatus updates the service control information for 
one or more correspondent nodes contained in this list. 
Since one or more correspondent nodes that become a 
communication partner of the mobile terminal equip- 
ment are known beforehand, and the service control in- 
formation is updated for the one or more correspondent 
nodes, the service control of the network can be effected 
on the basis of the service contents after change when 
a packet is transmitted from each correspondent node 
to the mobile terminal equipment. 
[0020] It is desirable that the home agent apparatus 
dynamically adds the address of a correspondent node 
that has newly communicated with the mobile terminal 
equipment to the list, and that sets the service control 
information to the newly added correspondent node. 
When the new correspondent node is added as the com- 
munication destination of the mobile terminal equip- 
ment, the list of addresses for the correspondent nodes 
is dynamically updated, and the service control informa- 
tion is set to the newly added correspondent node. 
Therefore, when a packet is transmitted from the newly 
added correspondent node to the mobile terminal equip- 
ment, the service control of the network can be made 
on the basis of the latest service contents at any time. 
[0021] It is desirable that the home agent apparatus 
has a list of addresses for the correspondent nodes that 
become a communication partner, and that the home 
sever apparatus sets the binding cache information in- 
dicating a connecting state between the mobile terminal 
equipment and the home agent apparatus to the corre- 
spondent nodes contained in the list, in a process at the 
initial registration phase of the mobile terminal equip- 
ment. Since a binding cache indicating on which path 
the communication takes place is set to the correspond- 
ent nodes that become a communication partner of the 
mobile terminal equipment at the initial registration 
phase, the latest service contents can be reflected when 
a packet is transmitted from the correspondent node to 
the mobile terminal equipment. 
[0022] The home agent apparatus desirably instructs 
all the correspondent nodes contained in the list to reset 
the binding cache information, when the foreign network 
to which the mobile terminal equipment is connected is 
changed. Since the contents of the binding cache infor- 
mation set in each correspondent node are updated 
every time when the mobile terminal equipment is 
moved and the foreign network connected thereto is 
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changed, the packet can be transmitted from the corre- 
spondent node to the mobile terminal equipment after 
movement. 

[0023] The home agent apparatus desirably deletes 
the unnecessary addresses of correspondent nodes s 
from the list by performing an aging process. By deleting 
the unnecessary addresses of correspondent nodes 
from the list, the network resources can be saved. 
[0024] When the processing in the correspondent 
nodes contained in the list is ended, it is desirable to 10 
omit a predetermined response message to be trans- 
mitted to the home agent apparatus. In the case where 
there are a great number of correspondent nodes con- 
tained in the list, a transmission/reception procedure of 
the response message to be transmitted from each cor- 15 
respondent node at the time when the setting of the 
service control information or binding cache is ended is 
omitted, thereby making it possible to reduce the time 
required for the setting and relieve the processing load. 
[0025] The mobile terminal equipment desirably al- 20 
lows the reference with indication to the content of the 
service control information set for each mobile terminal 
equipment on the basis of a registration response mes- 
sage transmitted from the foreign agent apparatus in 
correspondence to the registration request message. 25 
Since the user can know the content of the service con- 
trol information using the mobile terminal equipment, the 
prevention of false setting or the reconfirmation of the 
service content can be made easily. 
[0026] A service control information changing method 30 
in the mobile network of the invention comprises the 
steps of changing the service control information of the 
user that is managed in a home network to which the 
user of the mobile terminal equipment subscribes when 
the mobile terminal equipment is present in a foreign 35 
network other than the home network, transmitting a 
registration request message to the home network, after 
changing the service control information, transmitting 
the service control information after change from the 
home network having received the registration request 40 
message to the foreign network where the mobile ter- 
minal equipment is present, and receiving a service 
based on the service control information after change at 
the mobile terminal equipment in the foreign network. 
Since the service control information can be updated in 45 
accordance with a registration request message trans- 
mitted from the mobile terminal equipment, the mobile 
terminal equipment can receive the service based on 
the service control information after change in the for- 
eign network. so 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0027] 

55 

FIG. 1 is an overall block diagram of a mobile IP 
network of one embodiment to which the present 
invention is applied; 



FIG. 2 is a functional block diagram of each appa- 
ratus contained in the mobile IP network shown in 
FIG. 1; 

FIG. 3 is a table showing corresponding relations 
among a variety of kinds of messages input or out- 
put into or from functional entities contained in the 
mobile IP network of one embodiment; 
FIG. 4 is a table showing corresponding relations 
among a variety of kinds of messages input or out- 
put into or from functional entities contained in the 
mobile IP network of one embodiment; 
FIG. 5 is a table showing a format of a mobile IP 
protocol stack; 

FIG. 6 is a table showing a format of an IP header 
shown in FIG.5; 

FIG. 7 is a table showing a format of a UDP header 
shown in FIG.5; 

FIG. 8 is a table showing a format of an Ml P regis- 
tration request message; 

FIG. 9 is a table showing a format of an MN-SPC 
extension contained in the MIP registration request 
message shown in FIG. 8; 
FIG. 1 0 is a table showing a format of an MIP reg- 
istration reply message; 

FIG. 1 1 is a tableshowing aformat of an MIP binding 
update message; 

FIG. 1 2 is a table showing a format of a profile cache 
extension contained in the MIP binding update mes- 
sage shown in FIG. 11; 

FIG. 13 is a table showing a format of an MIP bind- 
ing acknowledge message; 
FIG. 1 4 is a table showing a format of a DIAMETER 
protocol stack; 

FIG. 1 5 is a table showing a format of a UDP header 
contained in the DIAMETER protocol stack shown 
in FIG.14; 

FIG. 1 6 is a table showing a format of a DIAMETER 
header; 

FIG. 1 7 is a table showing a format of an AMR (AA- 
Mobile-Node-Request) message; 
FIG. 1 8 is a table showing a format of an HMR (Au- 
thentication Request) message; 
FIG. 1 9 is a table showing a format of an AMA (AA- 
Mobile-Node-Answer) message; 
FIG. 20 is a table showing a format of an HMA (Au- 
thentication Response) message; 
FIG. 21 is a table showing a format of an SCR (Serv- 
ice Change Request) message; 
FIG. 22 is a table showing a format of an HMR 
(Service Change Answer) message; 
FIG. 23 is a table showing a format of a Service Pro- 
file Cache AVP included in the HMR message orthe 
like; 

FIG. 24 is a table showing a format of a profile data 
header; 

FIG. 25 is a table showing a format of a service pro- 
file; 

FIG. 26 is a functional block diagram showing a de- 
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tailed configuration of FA; 

FIG. 27 is a table showing the contents of the FA 
session transaction provided in the protocol control 
section; 

FIG. 28 is a table showing a specific example of the 5 
service profile cache which is set in the service con- 
trol section; 

FIG. 29 is a table showing a specific example of the 
visitor list which is set in the transfer control section; 
FIG. 30 is a flowchart showing a schematic opera- io 
tion procedure of FA involving the transmission or 
reception of the packet; 

FIG. 31 is a flowchart showing a message handling 
operation in FA; 

FIG. 32 is a table showing a specific example of the 15 
mobile connection that is set in the transfer control 
section; 

FIG. 33 is a table showing a specific example of the 
CN list that is set in the transfer control section; 
FIG. 34 is a table showing the contents of an HA 20 
session transaction provided in the protocol control 
section; 

FIG. 35 is a flowchart showing the operation of a 
message handling process in the case where the 
binding acknowledge is used in the HA; 25 
FIG. 36 is a flowchart showing the operation of a 
message handling process in the case where the 
binding acknowledge is not used in the HA; 
FIG. 37 is a flowchart showing the operation proce- 
dure for an aging process of the CN list in the HA; 30 
FIG. 38 is a flowchart showing the operation proce- 
dure of a CN list registering process in the HA; 
FIG. 39 is a table showing a specific example of the 
binding cache to be set in the transfer control sec- 
tion; 35 
FIG. 40 is a flowchart showing a message process- 
ing operation in the CN; 

FIG. 41 is a functional block diagram showing a de- 
tailed configuration of the MN; 

FIG. 42 is a table showing the contents of an agent 40 
list carried by the MN; 

FIG. 43 is a flowchart showing amessage process- 
ing operation in the MN; 

FIG. 44 is a view showing a display example on the 
user console; 45 
FIG. 45 is a flowchart showing the operation of a 
message transmission process in the MN; 
FIG. 46 is a functional block diagram showing a de- 
tailed configuration of the AAAF; 
FIG. 47 is a table showing the contents of the AAAF so 
session transaction provided in the protocol control 
section; 

FIG. 48 is a flowchart showing a message handling 
operation in the AAAF; 

FIG. 49 is a functional block diagram showing a de- 55 
tailed configuration of the AAAH; 
FIG. 50 is a table showing the contents of the AAAH 
session transaction provided in the protocol control 



section; 

FIG. 51 is a table showing the contents of SPDB; 
FIG. 52 is a table showing the contents of a service 
class table; 

FIG. 53 is a table showing a specific example of ap- 
plicable service contained in the service class table 
as shown in FIG. 53; 

FIG. 54 is a table showing the contents of four kinds 
of services; 

FIG. 55 is a table showing the contents of service 

proper information for the band control; 

FIG. 56 is a table showing the contents of applicable 

QoS; 

FIG. 57 is a flowchart showing the operation of a 

message handling process for the AAAH; 

FIG. 58 is a flowchart showing the operation of a 

message handling process for the AAAH; 

FIG. 59 is a table showing a specific example of a 

traffic management table; 

FIG. 60 is a table showing a specific example of a 
user contract database; 

FIG. 61 is a flowchart showing the operation of a 
service customizing process in the network re- 
source management system; 
FIG. 62 is a flowchart showing the operation of a 
traffic supervising process in the network resource 
management system; 

FIG. 63 is a diagram showing the sequence for the 
user to change the service within the range of con- 
tract service class: 

FIG. 64 is a flowchart showing the operation of a 
WUI process ; 

FIG. 65 is a flowchart showing the operation of a 
WUI process ; 

FIG. 66 is a diagram showing a list of screen to be 
displayed in the WUI process; 
FIG. 67 is a diagram showing a display example of 
the main screen; 

FIG. 68 is a diagram showing a display example of 

the service reference screen; 

FIG. 69 is a diagram showing a display example of 

the service change screen; 

FIG. 70 is a diagram showing a display example of 

the registration success screen; 

FIG. 71 is a diagram showing a display example of 

the error screen; 

FIG. 72 is a diagram showing a display example of 
the ISP authentication screen; 
FIG. 72 is a diagram showing a display example of 
the initial start screen for the user; 
FIG. 74 is a diagram showing the sequence for the 
user to change the service outside the range of con- 
tract service class; 

FIG. 75 is a diagram showing the sequence for the 
user to change the service within the range of con- 
tract service class; 

FIG. 76 is a diagram showing the sequence for the 
user to change the service within the range of con- 
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tract service class; 

FIG. 77 is a block diagram of the conventional net- 
work for explaining the concept of the PBN; and 
FIG. 78 is a block diagram of the conventional mo- 
bile IP network. 5 

DESCRIPTION OF THE PREFERRED EMBODIMENT 

[0028] A mobile IP network of one embodiment to 
which a mobile network system of the present invention 
is applied will be described below with reference to the 
drawings. The invention is applicable to the mobile IP 
protocols as defined in the RFC2002 and all the exten- 
sions in the future. 

Overall configuration and operation of network 

[0029] FIG. 1 is an overall block diagram of a mobile 
IP network of one embodiment to which the present in- 
vention is applied. FIG. 2 is a functional block diagram 
of each apparatus contained in the mobile IP network 
as shown in FIG. 1. 

[0030] As shown in FIG. 1 , the mobile IP network of 
this embodiment comprises a home network 100 con- 
nected via an IP transit network 900, three foreign net- 
works 200, 300, 400, and a network resource manage- 
ment system 500 connected to the home network 100. 
[0031] The home network 1 00 is one to which the user 
of an MN 600 (mobile terminal equipment, including the 
terminals movable from one place to another, for exam- 
ple, a notebook PC or portable terminal that supports 
the TCP/IP) subscribes, and includes an HA (home 
agent) 110 and an AAAH (authentication, authorization, 
accounting home server) 130. The HA 110 is a node for 
making the communication on behalf of the home net- 
work 100, and one of the functional entities as defined 
in an RFC 2002. The HA 11 0 has a home address as- 
signed to the MN 600, and is provided with a function of 
the router. Also, the HA 1 1 0 has both a mobile IP server 
function (MSF) and a DIAMETER client function (DCF). 
The AAAH 1 30 is an AAA (authentication, authorization, 
accounting) server of the home network 1 00 having the 
subscriber data of the authentication requesting user. 
The AAA server as used herein means a group of serv- 
ers for effecting the Authentication, Authorization and 
Accounting, and a name as employed in the IETF The 
AAAH 130 has an interface for user service contract 
change negotiation with the network resource manage- 
ment system 500, and performs an operation of setting 
a service profile to each functional entity (e.g., HA 110) 
within the home network 100 or other foreign networks 
200 to 400 in accordance with the result of negotiation. 
This AAAH 130 has a DIAMETER server function 
(DSF). 

[0032] In the present invention, there is no need of 
specifying the protocol (i.e., AAA protocol) used by the 
AAA server, but in this embodiment, a case of using the 
DIAMETER protocol under review in the IETF will be de- 



scribed below. The AAA protocol is mountable on all the 
protocols which can transfer the information as to the 
authentication, authorization, accounting and policy. To 
convey the new information required in the invention, an 
extensible attribute parameter called AVP as defined in 
the DIAMETER protocol is used. 
[0033] A foreign network 200 is one to which the MN 
600 is moved, including an FA (foreign agent) 210 and 
an AAAF (authentication, authorization, accounting for- 
eign server) 230. The FA 210 is a node for making the 
communication on behalf of the foreign network 200, 
and is one of the functional entities as defined in the 
RFC2002. This FA 21 0 has no home address assigned 
to the MN 600, but has a Care-of- Address that is an ad- 
dress of its own node, and is provided with a function of 
the router. Also, the FA 210 has both a mobile IP server 
function (MSF) and a DIAMETER client function (DCF), 
like the HA 1 1 0. The AAAF 230 is an AAA server of the 
network having no subscriber data of the authentication 
request user. The AAAF 230 specifies the AAAH 1 30 on 
the basis of an NAI (Network Access Identifier) of the 
user, and acts for the message exchange between the 
FA 21 0 and the AAAH 1 30. This AAAF 230 has a DIAM- 
ETER server function (DSF). 

[0034] A foreign network 300 is one which contains a 
CN (Correspondent Node) 320, and is connected, for 
example via a router 31 0, to the IP transit network 900. 
The CN 320 is a node for making the communication 
with the MN 600, and has a mobile IP client function 
(MCF). 

[0035] A foreign network 400 is one to which the MN 
600 is moved, including an FA (foreign agent) 410 and 
an AAAF (authentication, authorization, accounting for- 
eign server) 430. The FA 410 is a node for making the 
communication on behalf of the foreign network 400, 
and is one of the functional entities as defined in the 
RFC2002. The FA 410 and the AAAF 430 have the 
same configuration as the FA 210 and the AAAF 230 
contained in the foreign network 200 as described 
above. 

[0036] The network resource management system 
500 is a functional entity for managing the traffic situa- 
tion within the mobile IP network or the user service con- 
tract information in this embodiment. This network re- 
source management system 500 complies with a level- 
up contract from the user in accordance with a remain- 
ing situation of the network resources. Also, the network 
resource management system 500 has an interface with 
the AAAH 130 within the home network 100, and per- 
forms an operation via the interface in accordance with 
a service change request from the user. The interfaces 
for use may include SNMP, COPS, CLI, and HTTP. 
[0037] The mobile IP network of this embodiment has 
the above configuration, and its basic operation will be 
described below. For example, if an MN 600 belonging 
to the foreign network 200 is moved to the foreign net- 
work 400, the MN 600 makes a registration into the FA 
41 0 contained in the foreign network 400 and notifies its 
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own home address. This FA 410 registers the home ad- 
dress information of the MN 600 registered and its own 
care-of-address information into the HA 110 within the 
home network 100. Thereafter, a packet from the CN 
320 belonging to the foreign network 300 to the MN 600 
is transferred to the home network 100, using a home 
address of the MN 600, but the HA 110 captures, en- 
capsulates and transfers this packet to the FA 41 0 (tun- 
neling). The FA 410 that has received this encapsulated 
packet transfers the packet to the MN 600 by referring 
to the home address of the MN 600. The MN 600 that 
has received this packet can know an IP address of the 
CN 320 by referring to a transmission source IP address 
contained in a header section of the IP packet, and 
therefore can also transfer the packet directly to the CN 
320, neither via the FA410 northe HA 110. In this way, 
the packet can be transmitted or received between the 
MN 600 and the CN 320, without changing the IP ad- 
dress of the MN 600. 

[0038] The HA 1 1 0 corresponds to a home agent ap- 
paratus; the AAAH 130 corresponds to a home server 
apparatus; the FA210, 410 correspond to a foreign 
agent apparatus; the AAAF 230, 430 corresponds to a 
foreign server apparatus; and the network resource 
management system 500 corresponds to a network 
management system. Also, an SP (Service Profile) as 
will be described later corresponds to the service control 
information, and an SPDB (Service Profile Data Base) 
corresponds to a service information database. 
[0039] FIGS. 3 and 4 are tables showing the corre- 
sponding relations among a variety of kinds of messag- 
es input or output into orfrom the functional entities (MN, 
CN, HA, FA, AAAH, AAAF) contained in the mobile IP 
network of this embodiment. 

[0040] A variety of kinds of messages input or output 
into or from the functional entities are largely classified 
into a mobile IP message and a DIAMETER message. 
In FIGS. 3 and 4, an MIP (mobile IP) registration re- 
quest, an MIP registration reply, an MIP binding update, 
and an MIP binding acknowledge are the mobile IP mes- 
sages. Also, an HAR (HA registration request), an HAA 
(HA registration response), an AMR (AA-Mobile-Node- 
Request), an AMA (AA-Mobile-Node-Answer), an SCR 
(service change request), and an SCA (service change 
answer) are the DIAMETER messages. 
[0041] FIGS. 5 to 13 are tables showing the formats 
of mobile IP messages. FIG. 5 is a format table of a mo- 
bile IP protocol stack. As shown in FIG. 5, the mobile IP 
protocol stack contains an IP header, a UDP header, 
and a Mobile-IP field. 

[0042] FIG. 6 is a format table of the IP header as 
shown in FIG. 5. For example, this format is in the case 
(IPv4) where the IP version is 4. 
[0043] FIG. 7 is a format table of the UDP header as 
shown in FIG. 5. In the UDP header useful for the input 
or output of the mobile IP message, each value of a 
source port and a destination port is set to "434." 
[0044] FIG. 8 is a format table of the MIP registration 



request message stored in the Mobile-IP field as shown 
in FIG. 5. As shown in FIG. 8, the MIP registration re- 
quest message includes a home address, an HA ad- 
dress, a care-of-address, and a message identifier, and 

5 additionally includes an MN-HA authentication exten- 
sion, an MN-AAA authentication extension, an MN-NAI 
extension, and an MN-SPC extension. 
[0045] FIG. 9 is a format table of the MN-SPC exten- 
sion contained in the MIP registration request message 

10 as shown in FIG. 8. This MN-SPC extension contains 
an SP (Service Profile) as the service control informa- 
tion in a data field. 

[0046] FIG. 10 is a format table of the MIP registration 
reply message stored in the Mobile-IP field as shown in 
is FIG. 5. This MIP registration reply message includes a 
home address, an HA address, and a message identifi- 
er, and additionally includes an MN service profile ex- 
tension. 

[0047] FIG, 11 is a format table of the MIP binding up- 
20 date message stored in the Mobile-IP field as shown in 
FIG. 5. This MIP binding update message includes a 
home address, a care-of-address, and a message iden- 
tifier, and additionally includes a profile cache extension. 
[0048] FIG. 12 is a format table of the profile cache 
25 extension contained in the MIP binding update message 
as shown in FIG. 11. This profile cache extension in- 
cludes an SP (Service Profile) as the service control in- 
formation in a data field. 

[0049] FIG. 1 3 is a format table of the M IP binding ac- 

30 knowledge message stored in the Mobile-IP field as 
shown in FIG. 5. This MIP binding acknowledge mes- 
sage includes a home address and a message identifier. 
[0050] FIGS. 14 to 22 are the tables showing the for- 
mat of the DIAMETER message. FIG. 14 is a format ta- 

35 ble of a DIAMETER protocol stack. As shown in FIG. 
14, the DIAMETER protocol stack includes an IP head- 
er, a UDP header, a DIAMETER header, and a DIAME- 
TER payload. Herein, the IP header is the same as that 
of the mobile IP protocol stack as described above. 

40 [0051] FIG. 15 is a format table of the UDP header 
included in the DIAMETER protocol stack as shown in 
FIG. 14. In the UDP header useful for the input or output 
of the DIAMETER message, both a source port and a 
destination port are set to "RADIUS." 

45 [0052] FIG. 16 is a format table of the DIAMETER 
header included in the DIAMETER protocol stack as 
shown in FIG. 14. 

[0053] FIG. 1 7 is a format table of an AMR (AA-Mo- 
bile-Node-Request) message stored in the DIAMETER 

50 header and the DIAMETER payload included in the DI- 
AMETER protocol stack as shown in FIG. 14. Similarly, 
FIGS. 18,19, 20, 21 and 22 are format tables of an HAR 
message, an AMA message, an HAA message, an SCR 
message, and an SCA message, respectively. 

55 [0054] FIG. 23 is a format table of a Service- Profile- 
Cache AVP included in the HMR message, the AMA 
message, the HMA message, and the SCR message. 
FIG. 24 is a format table of a profile data h eader included 
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in the Service-Profile-Cache AVP as shown in FIG. 23. 
FIG. 25 is a format table of a service profile constituting 
a group of profiles included in the Service-Profile-Cache 
AVP as shown in FIG. 23. The service profile as shown 
in FIG. 25 has various Extensions appended corre- 5 
sponding to the services provided to each user. For 
example , IPSVC-DiffServe Extension, IPSVC-filter Ex- 
tension, IPSVC-security Extension, and IPSVC-Re- 
source Extension are appended corresponding to four 
services of the Diff-Serv, the packet filtering, the security 
service, and the band control. 

Detailed configuration and operation of functional 
entities 

[0055] The detailed configuration and operation of 
functional entities such as FA210, HA110 and so on will 
be described below. 

FA 

[0056] FIG. 26 is a functional block diagram showing 
a detailed configuration of an FA 21 0. As shown in FIG. 
26, the FA 21 0 comprises a packet control section 21 2, 
a protocol control section 214, a service control section 
216, and a transfer control section 218. Note that an FA 
41 0 has the same configuration as the FA 21 0, and the 
FA 21 0 will be only described below in detail. 
[0057] The packet control section 212 has a packet 
filter function to bracketthe packets into a protocol pack- 
et and a data packet by discriminating the packet head- 
er. Also, it performs the editing and transfer process of 
packets in accordance with an instruction of the service 
control section 21 6 and the transfer control section 21 8. 
[0058] The protocol control section 214 performs the 
processing for the mobile IP and the DIAMETER proto- 
col. This protocol control section 214 has an FA session 
transaction for managing a DIAMETER session to set 
the SPC (Service Profile Cache). 
[0059] FIG. 27 is a table showing the contents of the 
FA session transaction provided in the protocol control 
section 214. As shown in FIG. 27, the FA session trans- 
action includes a session ID and a session timer. The 
"session ID" is the NAI of the MN 600. The "session tim- 
er" indicates the term of validity for this transaction. 
[0060] The service control section 21 6 has a service 
profile cache that is a set of service control information. 
[0061] FIG. 28 is a table showing a specific example 
of the service profile cache which is set in the service 
control section 216. Note that this service profile cache 
is also provided not only in the FA 210 but also in the 
HA 110 or CN 320. As shown in FIG. 28, the service 
profile cache includes a profile number, an object entity, 
a source IP address, a source net mask, a destination 
address, a destination net mask, a source port number, 
a destination port number, and the band control exten- 
sion information. This band control information contains 
the service type, the QoS class, the band upper limit, 



and the presence or absence of band assurance. 
[0062] The transfer control section 218 has a visitor 
list as the service proper control data that is required to 
manage the mobile IP. 

[0063] FIG. 29 is a table showing a specific example 
of the visitor list that is set in the transfer control section 
218. As shown in FIG. 29, the visitor list contains an IP 
source address, a link layer source address, a UDP 
source port, an HA address, a registration request iden- 
tifier field, a life time, and the authentication information. 
The "IP source address" is a home address of the MN 
600 that is notified with the MIP registration request 
message or AMA message. The "link layer source ad- 
dress" is an address of the link layer (MAC) in the MN 
600. The "UDP source port" is a UDP source port 
number of the MN 600. The "HA address" is an address 
of the HA 1 1 0 forforwarding the MIP registration request 
message, and is notified to the FA 210, using the MiP 
registration request message or AMA message. The 
"registration request identifier field" is one for associat- 
ing the request message with the response message. 
The "life time" is the term of validity for the MIP registra- 
tion request message. The "authentication information" 
is the authentication information useful for the FA 210 
to authenticate the MN 600. 

[0064] The FA 100 has such a configuration, and its 
schematic operation will be described below. FIG. 30 is 
a flowchart showing a schematic operation procedure 
of the FA 1 00 involving the transmission or reception of 
the packet. 

[0065] The packet control section 212 receives a 
packet and then extracts the IP header information con- 
tained in the received packet (step S1 ). Then, the packet 
control section 212 determines whether or not the re- 
ceived IP packet is a data packet or a protocol packet, 
on the basis of the reception address and the port 
number contained in the extracted IP header informa- 
tion (step S2). 



[0066] In the case where the received IP packet is the 
protocol packet, a protocol processing request is issued 
from the packet control section 21 2 to the protocol con- 
trol section 214. The protocol control section 21 4 brack- 
ets the message type of the received message into a 
mobile IP message and a DIAMETER message, based 
on the port number contained in the UDP header as 
shown in FIGS. 7 and 15 (step S3). 
[0067] If the message type is the DIAMETER mes- 
sage and a service profile cache AVP is contained in the 
message, the service control section 216 retrieves and 
changes the service profile cache (step S4). The trans- 
fer control section 218 generates and updates the serv- 
ice proper control data (visitor list) corresponding to the 
received DIAMETER message, and then transmits a 
message as defined in the protocol (step S5). 
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Case of data packet 

[0068] In the case where the received I P packet is the 
data packet, the packet control section 212 sends the 
extracted head information and makes a retrieval re- 5 
quest to the service control section 216. The service 
control section 216 retrieves the matched service pro- 
file, and edits the packet on the basis of the routing/ 
packet editing information contained therein (step S6). 
The transfer control section 218 determines a packet 
forwarding destination by referring to the service proper 
control data (visitor list) (step S7), and forwards the ed- 
ited packet to this forwarding destination (step S8). 
[0069] In this way, the FA 21 0 discriminates the type 
of received packet and performs a process in accord- 
ance with the type of packet. 

[0070] The processing according to the message type 
that is performed in the FA 21 0 having received the pro- 
tocol packet will be described below. 
[0071] FIG. 31 is a flowchart showing a message han- 
dling operation in the FA 210. The operation of the FA 
210 will be described below using this flowchart. Note 
that the operation of other FA 41 0 is similarly performed. 

Process in the case where the MIP registration request 
message is received 

[0072] The FA 210 checks the message type (step 
S100). If the MIP registration request message is deter- 
mined, the content of MN-NAI extension contained in 
this message is retrieved (step S1 01). Then a check is 
made to see whether or not the FA session transaction 
exists (step S1 02). If there is no FA session transaction, 
the FA 21 0 creates a new FA session transaction (step 

5103) . Thereafter or immediately if the FA session 
transaction exists, a check is made to see whether or 
not the MN-AAA authentication extension exists (step 

5104) . 

[0073] If the MN-AAA authentication extension does 
not exist, the FA 210 forwards an MIP registration re- 
quest to the HA 110, judging that the MIP registration 
request message has been transmitted for the periodi- 
cal registration refresh (step S105). If the MN-AAA au- 
thentication extension is contained in the received MIP 
registration request message, the FA 210 further checks 
to see whether or not the MN-SPC extension exists in 
this message (step S106). 

[0074] If the MN-SPC extension exists, the FA 210 
creates an MN-SPC-AVP (step S1 07). Then the FA 21 0 
creates and sends an AMR message with this created 
AVP stored at a predetermined location to the AAAF 230 
(step S1 08). 

Process in the case where the MIP registration reply 
message is received 

[0075] The FA 210 checks the message type (step 
S100). If the MIP registration reply message is deter- 



mined, the FA 210 forwards this message to the corre- 
sponding MN 600 (step S110). 

Case where the AMA message is received 

[0076] The FA 210 checks the message type (step 
S100). If the AMA message is determined, the FA 210 
reads and sets an SPC (Service- Profile-Cache AVP) 
contained in this message as the SPC carried within the 
service control section 216 of its own (step S120). 
[0077] Also, the FA 21 0 makes a check of whether or 
not the MN-SPC-AVP exists within this received AMA 
message (step S121). If so, the FA 210 creates the MN 
service profile extension (step S1 22). Then, the FA 21 0 
creates an MIP registration reply message having this 
MN service profile extension stored at a predetermined 
location and sends out this message to the MN 600 (step 
S123). 

Case where the SCR message is received 

[0078] The FA 210 checks the message type (step 
S100). If the SCR message is determined, the FA 210 
reads and sets an SPC (Service-Profile-Cache AVP) 
contained in this message as the SPC carried within the 
service control section 21 6 of its own (step S1 30). Then, 
the FA 21 0 creates and sends an SCA message to the 
AAAF 230 (stepS131). 

HA 

[0079] The HA 1 1 0 has fundamentally the same con- 
figuration as that of the FA 21 0 as shown in FIG. 26, but 
has different contents of data held in the protocol control 
section 214 and the transfer control section 218. More 
specifically, the transfer control section 218 within the 
HA 11 0 carries the mobile connection and a CN list. Al- 
so, the protocol control section 214 carries the HA ses- 
sion transaction. 

[0080] FIG. 32 is a table showing a specific example 
of the mobile connection that is set in the transfer control 
section 21 8. As shown in FIG. 32, the mobile connection 
includes a home address, a care-of-address, a registra- 
tion request identifier field, a life time, and the authenti- 
cation information. The "home address" is one assigned 
to the MN 600. The "care-of-address" is an IP address 
of the FA 21 0 (or 41 0) to which the MN 600 is currently 
connected. The "registration request identifier field" is 
one for associating the request message with the re- 
sponse message. The "life time" is the term of validity 
for the registration request. The "authentication informa- 
tion" is the information for the HA 110 to authenticate 
the MN 600. 

[0081] FIG. 33 is a table showing a specific example 
of the CN list that is set in the transfer control section 
21 8. As shown in FIG. 33, the CN list includes a CN ad- 
dress, a life time, and a message identifier. The "CN ad- 
dress" is one at which the MIP binding update message 
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has been transmitted. The "life time" is the term of va- 
lidity for the aging process. The "message identifier" is 
one with which the updated binding has been brought 
about. 

[0082] FIG. 34 is a table showing the contents of an 
HA session transaction provided in the protocol control 
section 21 4. As shown in FIG. 34, the HA session trans- 
action includes a session ID, a session timer, a mobile 
connection, an SCR request flag, and an SCR request 
source address. The "session ID" is an ID indicating the 
NAI of the MN 600. The "session timer 41 indicates the 
term of validity for this transaction. The "mobile connec- 
tion" indicates a pointer to the mobile connection. The 
"SCR request flag" is a flag indicating that the service 
profile of the CN 320 is being changed. The "SCR re- 
quest source address" is an IP address of the functional 
entity that has transmitted an SCR message, namely, 
made a service change request. 
[0083] The operation procedure of the HA 1 1 0 involv- 
ing transmission or reception of the packet is substan- 
tially the same as that of the FA 210, and can be per- 
formed directly in accordance with the flowchart as 
shown in FIG. 30. The process according to the mes- 
sage type that is performed in the HA 110 having re- 
ceived the protocol packet will be described below. 
[0084] FIG. 35 is a flowchart showing the operation of 
a message handling process in the case where the bind- 
ing acknowledge is used in the HA 110. The process of 
the HA 1 1 0 will be described below using this flowchart. 

Process in the case where the Ml P binding update 
message is transmitted to the CN in accordance with 
the CN entry 

[0085] The HA 110 checks the message type (step 
S200). If the HAR message is determined, the HA ses- 
sion transaction is retrieved on the basis of the user NAI 
contained in this message (step S201 ). Then a check is 
made to see whether or not the HA session transaction 
exists (step S202). If there is no HA session transaction, 
the HA 11 0 creates a new HA session transaction (step 
S203). 

[0086] Then, the HA 110 creates an MIP mobile con- 
nection message (step S204), and reads out the SPC 
(Service- Profile-Cache AVP) contained in the HAR 
message and sets it as the SPC carried in the service 
control section 216 of its own (step S205). 
[0087] Further, the HA 1 1 0 makes a check of whether 
or not there is any CN entry that has not transmitted the 
binding update message (step S206). If not, the HA 1 1 0 
creates and sends an HAA message to the AAAH 130 
(step S207). If there is any CN entry that has not trans- 
mitted the binding update message, the HA 1 1 0 creates 
and sends an MIP binding update message containing 
the SPC extension to this CN (step S208). 



Process in the case where the binding acknowledge is 
received 

[0088] The HA 110 checks the message type (step 
5 S200). If the MIP binding acknowledge message is de- 
termined, the HA 110 transfers to the step S206. That 
is, if there is no CN entry that has not transmitted the 
binding update message, the HA 1 1 0 creates and sends 
an HAA message to the AAAH 1 30 (step S207). If there 
10 is any CN entry that has not transmitted the binding up- 
date message, the HA 110 stores the profile cache ex- 
tension, and further creates an MIP binding update mes- 
sage with the "A" bit turned on to send this message to 
this CN (step S208). 

15 

Process in the case where the MIP registration reply 
message is received 

[0089] The HA 110 checks the message type (step 
20 S200). ff the MIP registration request message is deter- 
mined, the content of MN-NAl extension contained in 
this message is retrieved (step S210). Then, a check is 
made to see whether or not the HA transaction exists 
(step S211). If there is no HA transaction, the HA 110 
25 creates a new HA transaction (step S212). Thereafter, 
or immediately if the HA transaction exists, the HA 11 0 
creates and sends an MIP registration reply message 
to the FA (step S213). 

30 Case where the SCR message is received 

[0090] The HA 210 checks the message type (step 
S200). If the SCR message is determined, the SPC 
(Service-Profile-Cache AVP) contained in this message 
35 js read and set as the SPC carried in the service control 
section 216 of its own (step S220). Then, the HA 210 
creates and sends an SCA message to the AAAH 130 
(step S221). 

[0091] FIG. 36 is a flowchart showing the operation of 
40 a message handling process in the case where the bind- 
ing acknowledge is not used in the HA 1 1 0. The process 
of the HA 110 will be described below using this flow- 
chart. 

45 Process in the case where the binding update message 
is transmitted to the CN in accordance with the CN entry 

[0092] The operation where the HAR message is re- 
ceived is fundamentally the same as that of steps S201 

so to S207 as shown in FIG. 35, except for the operation 
after an affirmative judgement is made at step S206 be- 
cause there is the CN entry that has not transmitted the 
binding update message. That is, if there is the CN entry 
that has not transmitted the binding update message, 

55 the HA 110 stores the profile cache extension, and fur- 
ther creates an MIP binding update message with the 
"A" bit turned off to send this message to all the CNs 
(step S230). 
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[0093] The operation in the case where the Ml P reg- 
istration request message is received is the same as 
that at steps S210 to S213 as shown in FIG. 35. The 
operation in the case where the SCR message is re- 
ceived is the same as that at steps S220 and S221 as 
shown in FIG. 35. 

[0094] In this way, in the case where no binding ac- 
knowledge is used, the MIP binding acknowledge mes- 
sage sent from the CN 320 is omitted, thereby making 
the transmission and reception process of this message 
unnecessary. Particularly, in the case where there are a 
great number of CNs 320 with which the MN 600 com- 
municates, the processing loads of both the HA 1 1 0 and 
the CN 320, or the accompanying costs can be reduced. 
[0095] FIG. 37 is a flowchart showing the operation 
procedure for an aging process of the CN list in the HA 
110. The aging process of the CN list in the HA 1 1 0 will 
be described below using this flowchart. Note that the 
aging process of the CN list is one for removing old CN 
entries from the CN list. This aging process is performed 
at every fixed time interval, and this fixed time interval 
is counted by a timer for the aging process. 
[0096] If the aging process is started, the HA 110 
checks the entries in the CN list in the transfer control 
section 218 (step S240). As shown in FIG. 33, the CN 
list contains the CN addresses at which the Ml P binding 
update message has been sent. A list of these'address- 
es is directly used as the CN entries. 
[0097] The HA 1 1 0 makes a check of whether or not 
the life time for each CN entry is equal to or less than 
zero (step S241), and abolishes the CN entry in which 
the life time is equal to or less than zero (step S242). 
For the entry in which the life time is greater than zero, 
the HA 110 subtracts a predetermined value from the 
present life time to update the life time (step S243). 
[0098] Then, the HA 110 sets a timer for the aging 
process (step S244), and terminates the aging process 
for the entries in the CN list. 

[0099] In this way, the aging process for the CN list is 
performed to delete the unnecessary address of the CN 
320 from the CN list to save the network resources. 
[0100] FIG. 38 is a flowchart showing the operation 
procedure of a CN list registering process in the HA 1 1 0. 
The CN list registering process will be described below 
using this flowchart. 

[0101] The HA 11 0 checks the IP address (i.e., desti- 
nation address and source address) of the received data 
packet (step S250). A check is made to see whether or 
not the source address of packet of which the destina- 
tion address is a home address of the MN 600 exists in 
theCN list (step S251). 

[0102] If not, the HA 110 newly registers this source 
address in the CN list (step S252) . Also, the HA 1 1 0 cre- 
ates and sends an MIP binding update message to the 
CN (step S253). 



CN 

[0103] The CN 320 has fundamentally the same con- 
figuration as the FA 210 as shown in FIG. 26, except for 
5 the contents of service proper control data carried in the 
transfer control section 218. More specifically, the trans- 
fer control section 21 8 within the CN 320 carries a bind- 
ing cache. 

[0104] FIG. 39 is a table showing a specific example 

10 of the binding cache to be set in the transfer control sec- 
tion 218. As shown in FIG. 39, the binding cache in- 
cludes a home address, a care-of-address, a life time, 
and an encapsulation method. The "home address" is 
one assigned to the MN 600. The "care-of-address" is 

15 an IP address of the FA 210 (or 410) at which the MN 
600 is connected at present. The "life time" is the term 
of validity for the binding cache. The "encapsulation 
method" is one for the packet transmitted or received 
between the CN 320 and the FA 210, 41 0. 

20 [0105] The operation procedure of the CA 320 involv- 
ing transmission or reception of the packet is substan- 
tially the same as that of the FA 210, and may be per- 
formed directly in accordance with that as shown in FIG. 
30. The process according to the message type that is 

25 performed in the CN 320 having received the protocol 
packet will be described below. 
[0106] FIG. 40 is aflowchart showing amessage 
processing operation in the CN 320. The setting process 
with the binding cache or SPC by the CN 320 will be 

30 described below using this flowchart. 

[0107] The CN 320 checks the message type (step 
S300). If the MIP binding update message is deter- 
mined, the session transaction is retrieved on the basis 
of the user NAI contained in this message (step S301). 

35 Then a check is made to see whether or not the session 
transaction exists (step S302). If not, the CN 320 creates 
a new session transaction (step S303). 
[0108] Then, the CN 320 creates and updates the 
binding cache on the basis of the care-of-address and 

40 the home address contained in the binding update mes- 
sage (step S304). Also, the CN 320 reads out the profile 
cache extension contained in the binding update mes- 
sage and sets it as the SPC carried in the service control 
section 216 of its own (step S305). Then the CN 320 

45 determines whether or not the "A" bit in the binding up- 
date message is ON (step S306). If the "A" bit is ON, a 
binding acknowledge message is created and transmit- 
ted to the HA 110. On the other hand, if the "A" bit is 
OFF, the binding acknowledge message is not created, 

50 and the reply process to the HA 110 is omitted. 

MN 

[0109] FIG. 41 is a functional block diagram showing 
55 a detailed configuration of the MN 600. As shown in FIG. 
41 , the MN 600 comprises a packet control section 61 0 
and a protocol control section 620. The packet control 
section 610 has a packet filter function. The protocol 
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control section 620 performs a process for dealing with 
the mobile IP and HTTP, and has a user configuration 
file. 

[0110] FIG. 42 is a table showing the contents of an 
agent list carried by the MN 600. This agent list contains 
a list of care-of-addresses in the router advertisement, 
for example, two care-of-addresses 1 and 2. 
[01 1 1 ] The schematic operation of the M N 600 will be 
described below. 

[0112] FIG. 43 is a flowchart showing amessage 
processing operation in the MN 600. The packet receiv- 
ing process of the MN 600 will be described below using 
this flowchart. 

Operation for displaying the MN service profile 
extension on the console 

[0113] The MN 600 checks the message type on the 
basis of the received packet (step S400). If the MIP reg- 
istration reply message is determined, an initial mes- 
sage check process for the registration response is per- 
formed (step S401). 

[01 1 4] The MN 600 makes a check of whether or not 
the MN service profile extension exists in the received 
MIP registration reply message (step S402). If so, the 
MN service profile extension is taken out and displayed 
on the user console (step S403). FIG. 44 is a view show- 
ing a display example on the user console. The user 
watching this display can know the detailed contents of 
the SPC and can easily prevent the false setting or 
reconfirm the service contents. 

Operation for storing the MN-SPC extension during the 
request for the MIP registration at the hand-off time 

[0115] The MN 600 checks the message type (step 
S400). If the router advertisement is determined, the 
care-of-address contained in this router advertisement 
is checked (step S410). Then a check is made to see 
whether or not any care-of-address is not contained in 
the agent list (step S411). 

[0116] If the care-of-address not contained in the 
agent list exists , the MN 600 creates the FA-NAI exten- 
sion, the MN-AAA authentication extension and the old 
FA-NAI extension and stores them in an MIP registration 
request message (step S41 2). Also, the MN 600 checks 
the user configuration file (step S413), and determines 
whether or not a profile reference flag is ON (step S41 4). 
If the profile reference flag is ON, the MN 600 stores the 
MN-SPC extension in the MIP registration request mes- 
sage (step S415). Then, the MN 600 sends out the MIP 
registration request message to the FA that has origi- 
nated the router advertisement (step S416). 
[01 1 7] FIG. 45 is a flowchart showing the operation of 
a message transmission process in the MN 600. For ex- 
ample, an operation procedure for transmitting asyn- 
chronously an MIP registration request message upon 
a command initiation on the user console is shown. The 



packet transmission process of the MN 600 will be de- 
scribed below using this flowchart. 
[0118] A process for creating the MIP registration re- 
quest message is initiated from the user console, or ow- 

5 ing to the service change, from a local window of the 
user (step S420). The MN 600 creates the MN-AAA au- 
thentication extension and the MN-NAI extension and 
stores them in an MIP registration request message 
(step S421). Also, the MN 600 checks the user config- 

10 uration file (step S422), and determines whether or not 
the profile reference flag is ON (step S423). If the profile 
reference flag is ON, the MN 600 creates the MN-SPC 
extension, and stores it in the MIP registration request 
message (step S424). Then the MN 600 sends out the 

15 MIP registration request message to the nearest FA to 
which the MN 600 is moved (step S425). 

AAAF 

20 [0119] FIG. 46 is a functional block diagram showing 
a detailed configuration of the AAAF 230 (or 430). As 
shown in FIG. 46, the AAAF 230 comprises a packet 
control section 232, a protocol control section 234 and 
a service management section 236. 

25 [0120] The packet control section 232 has a packet 
filter function to bracket the packets into an AMR mes- 
sage, an AMA message, an SCR message and an SCA 
message by discriminating the packet header. The pro- 
tocol control section 234 is to support a DIAMETER pro- 

30 tocol to perform a predetermined process in accordance 
with various kinds of messages received. Also, the pro- 
tocol control section 234 has an AAAF session transac- 
tion to manage the DIAMETER session. 
[0121] FIG. 47 is a table showing the contents of the 

35 AAAF session transaction provided in the protocol con- 
trol section 234. As shown in FIG. 47, the AAAF session 
transaction includes a session ID, an AAAH address, an 
HA address, an old FA-NAI, a present FA-NAI, an SCR 
request source address, an SPC session timer, and a 

^o status. The "session ID" is an ID indicating the NAI of 
the MN 600. The "AAAH address" is an IP address of 
the AAAH 130 specified by the NAI of the MN 600. The 
"HA address" is an IP address of the HA 110 assigned 
by the AAAF 1 30. The "old FA-NAI" is the NAI of the old 

45 FA where the connected FA is changed because the MN 
600 is moved. The "present FA-NAI" is the NAI of the 
FA to which the MN 600 is connected at present. The 
"SCR request source address" is an IP address of the 
AAAH 130 that has transmitted an SCR message, or 

50 made a service change request. The "session timer" is 
the term of validity for this transaction. The "status" in- 
dicates an operation status of the AAAF, such as a proc- 
ess waiting, HA requesting, AMA processing, HA 
change requesting, and FA change requesting. 

55 [0122] The AAAF 230 has such a configuration, and 
its operation will be described below. 
[01 23] FIG. 48 is a flowchart showing a message han- 
dling operation in the AAAF 230. The operation of the 
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AAAF 230 will be described below using this flowchart. 

Process in the case where the AMR message is 
received 

5 

[01 24] The AAAF 230 checks the message type (step 
S500). If an AMR message is determined, the AAAF 
session transaction is retrieved on the basis of the user 
NAI contained in this message (step S501). Then a 
check is made to see whether or not the AAAF session 10 
transaction exists (step S502). If the AAAF session 
transaction does not exist, the AAAF 230 creates a new 
AAAF session transaction (step S503). 
[0125] Then the AAAF 230 specifies the AAAH 130 
on the basis of the user NAI contained in the AM R mes- is 
sage, and forwards the AMR message to this specified 
AAAH 130 (step S504). 

Process in the case where the AMA message is 

received 20 

[01 26] The AAAF 230 checks the message type (step 
S500). If an AMA message is determined, the SPC con- 
tained in the AAAF session transaction is set (step 
S51 0). Then the AAAF 230 forwards the received AMA 25 
message to the FA (step S511 ). 

Process in the case where the SCR message is 
received 

30 

[01 27] The AAAF 230 checks the message type (step 
S500). If an SCR message is determined, the SPC con- 
tained in the AAAF session transaction is set (step 
S520). Then the AAAF 230 forwards the received SCR 
message to the FA (step S521 ). 35 

Process in the case where the SCA message is received 

[01 28] The AAAF 230 checks the message type (step 
S500). If an SCA message is determined, the AAAF 230 40 
forwards the received SCA message to the AAAH 1 30 
(step S530). 

AAAH 

45 

[0129] FIG. 49 is a functional block diagram showing 
a detailed configuration of the AAAH 130. As shown in 
FIG. 49, the AAAH 130 comprises a packet control sec- 
tion 132, a protocol control section 134 and a service 
management section 136. so 
[0130] The packet control section 132 has a packet 
filter function to bracket the packets into an AMR mes- 
sage, an HAA message, and an SCA message by dis- 
criminating the packet header. The protocol control sec- 
tion 1 34 is to support a DIAMETER protocol to perform 55 
a predetermined process in accordance with various 
kinds of messages received. Also, the protocol control 
section 134 has an AAAF session transaction to man- 
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age a DIAMETER session. 

[0131] FIG. 50 is a table showing the contents of the 
AAAH session transaction provided in the protocol con- 
trol section 1 34. As shown in FIG. 50, the AAAH session 
transaction includes a session ID, an HA address, an 
HA assigned AAAF address, a present AAAF address, 
an old AAAi- address, a session timer, an SPC, and a 
status. The "session ID" is an ID indicating the NAI of 
the MN 600. The "HA address" is an IP address of the 
HA 110 assigned by the AAAH 130. The "HA assigned 
AAAF address" is an IP address of the AAAF to which 
the AAAH 130 has requested to assign the HA. The 
"present AAAF address" is an IP address of the AAAF 
that has transmitted the AMR message, or made an au- 
thentication request. The "old AAAF address" is an IP 
address of the old AAAF when the AAAF is changed. 
The "session timer" is the term of validity for this trans- 
action. The "status" indicates an operation status of the 
AAAH, such as a process waiting, HA requesting, HA 
change requesting, and FA change requesting. 
[0132] The service management section 136 has an 
SPDB (Service Profile Data Base) and an SPC (Service 
Profile Cache). The SPDB is a database for storing the 
common information to all the users , such as a service 
class orQoS class, and is constituted of the SP (Service 
Profile) in a unit of NAI. This SP is constituted of the NAI 
for identifying the user and a service block having a dif- 
ferent configuration depending on the service type. The 
service block includes a service class , an operable 
service type, and the service proper information. The 
service proper information for band control includes the 
QoS, the available band, and the presence or absence 
of band assurance. 

[0133] FIG. 51 is a table showing the contents of SP- 
DB. As shown in FIG. 51 , the SPDB includes a user NAI , 
a user SPI, a user contract service class, and an actual 
service class used by the user. The "user NAI" is the 
NAI of the MN 600. The "user SPI" is a service profile 
identifier for use when authenticating the user. The "user 
contract service class" indicates the available service of 
this class, QoS, and the maximum number of profiles. 
The "actual service class used by the user" is a contract 
service class of the user by default, but may be a higher 
level service class depending on the service condition 
of network under supervision of the network resource 
management system 500. 

[0134] FIG. 52 is a table showing the contents of a 
service class table. As shown in FIG. 52, the service 
class table includes a service class identifier, an appli- 
cable service, and the maximum number of profiles. The 
"service class identifier" is one indicating the service 
class, for example, any number from "0" to "3" is set. 
The "applicable service" indicates the content of avail- 
able service in a unit of service class, and a specific ex- 
ample will be described later. The "maximum number of 
profiles" is concerned with the maximum number of pro- 
files that is allowable for this service class. 
[0135] FIG. 53 is a table showing a specific example 
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of applicable service contained in the service class table 
as shown in FIG. 53. As shown in FIG. 52, the content 
of applicable service is set corresponding to the service 
type "0" to "3." The applicable services include a Diffserv 
(Differentiated Service), a packet filtering, a security 
service and a band control. For each service class, the 
ON/OFF indicating that the service is applicable or not 
is set. 

[0136] FIG. 54 is a table showing the contents of four 
kinds of services as described above. As shown in FIG. 
54, four kinds of services are associated with the num- 
bers of "1 " to "4." "1 " corresponds to the Diffserv (Differ- 
entiated Service), indicating a service on the basis of 
the RFC (Request for Comments ) 2474, 2475. "2" cor- 
responds to the packet filtering, indicating a service for 
filtering the packet with the IP address of the packet or 
the port number. "3" corresponds to the security service, 
indicating a secure service using the IPSEC. "4" corre- 
sponds to the band control, indicating a service for con- 
trolling the available band for each MN. Note that "O" is 
the reserved value for the future use. 
[01 37] FIG. 55 is a table showing the contents of serv- 
ice proper information for the band control. As shown in 
FIG. 55, an applicable QoS is set for every class iden- 
tified by the class identifier. The contents of the applica- 
ble QoS in FIG. 55 are shown in FIG. 56. That is, five 
kinds of applicable QoS, "0" to "4," are prepared as 
shown in FIGS. 55 and 56. No band control service is 
applied to a service class corresponding to the class 
identifier "0" (with no available band and no band assur- 
ance). The band control service with a usable band of 
0 to 100 kbps and the band assurance is applied to a 
service class corresponding to the class identifier "1 ." 
The band control service with a usable band of 0 to 255 
kbps and without the band assurance is applied to a 
service class corresponding to the class identifier "2." 
The band control service with a usable band of 0 to 51 2 
kbps and without the band assurance is applied to a 
service class corresponding to the class identifier "3." 
The band control service with a usable band of 0 to 1 500 
kbps and without the band assurance is applied to a 
service class corresponding to the class identifier "4." 
[0138] The AAAH 130 has such a configuration, and 
its operation will be described below. 
[0139] FIGS. 57 and 58 are a flowchart showing the 
operation of a message handling process for the AAAH 
130. The operation of the AAAH 130 will be described 
below using this flowchart. 

Process in the case where the AMR message is 
received 

[0140] First of all, the operation of creating the SPC 
and sending out an HAR message after receiving an 
AMR message with the service change or hand-off of 
the MN as a moment will be described below. The AAAH 
130 checks the received message type (step S600). If 
the AMR message is determined, a check is made to 



see whether or not the corresponding AAAH session 
transaction exists (step S601). If the AAAH session 
transaction does not exist, the AAAH 130 produces a 
new AAAH session transaction (step S602). 

s [0141] Then the AAAH 130 retrieves the SPDB using 
a user NAI, and creates an SPC corresponding to the 
service class on the basis of the retrieved information 
(step S603). The AAAH 1 30 stores the SPC in the AAAH 
session transaction (step S604). 

10 [01 42] Also, the AAAH 1 30 makes a check of whether 
or not the MN-SPC AVP exists in the received AMR mes- 
sage (step S605). If it exists, the AAAH 130 retrieves 
the service class actually used by the user within the 
SPDB, using the NAI, and creates an SPC on the basis 

15 of the retrieved result (step S606). The AAAH 130 cre- 
ates an HAR message containing the SPC or various 
kinds of AVP to send it to the HA 110 (step S607). 

Operation in the case where the HAA message is 
20 received 

[01 43] The AAAH 1 30 checks the message type (step 
S600). If an HAA message is determined, the AAAH 130 
reads the SPC stored in the service management sec- 
25 tion 1 36, and creates an AMA message with the service 
profile cache AVP (Service- Profile-Cache AVP) contain- 
ing this SPC to be sent out to the AAAF (step S610). 

Process in the case where the service class is changed 

30 

[0144] The operation of recreating the SPC and send- 
ing out an SCR message when the service class is 
changed as demanded by the network resource man- 
agement system 500 will be described below. 

35 [0145] The AAAH 130 checks the received message 
type (step S600). If a service class change request mes- 
sage from the network resource management system 
500 is determined, the AAAH 130 makes a check of 
whether or not the AAAH session transaction exists, us- 

40 ing the user NAI (stepS620). If the AAAH session trans- 
action does not exist, the AAAH 1 30 creates and sends 
out a service class change response message notifying 
the abnormal end to the network resource management 
system 500 (step S621). 

45 [0146] If the AAAH session transaction exists, the 
AAAH 130 retrieves the SPDB using the user NAI, and 
creates an SPC corresponding to the requested service 
class (step S622) . And the AAAH 1 30 stores the created 
SPC in the AAAH session transaction (step S623), and 

50 creates and sends out an SCR message with the service 
profile cache AVP (Service-Profile-Cache AVP) contain- 
ing the created SPC to the HA 11 0 (step S624). 

Operation in the case where the SCA message is 
55 received 

[01 47] The AAAH 1 30 checks the message type (step 
S600). If an SCA message is determined, the source of 
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this message is checked (step S630). In the case where 
the source is the HA 1 1 0, the AAAH 1 30 reads the SPC 
stored in the service management section 1 36, and cre- 
ates and sends an SCR message with the service profile 
cache AVP (Service-Profile-Cache AVP) containing this 5 
SPC to the AAAF (step S631). In the case where the 
source is the AAAF, the operation transfers to step 
S621 , where a service class change response message 
is created and sent to the network resource manage- 
ment system 500. 

Network resource management system 

[0148] The network resource management system 
500 is an entity for managing a traffic situation within the 
network and the user contract information. This network 
resource management system 500 complies with a lev- 
el-up contract from the user in accordance with a re- 
maining situation of network resources. Also, the net- 
work resource management system 500 has an inter- 
face with the AAAH 130 within the home domain, and 
performs an operation via the interface in accordance 
with a service change request from the user. The inter- 
faces available may include SNMP, COPS, CLI and HT- 
TP. 

[0149] FIG. 59 is a table showing a specific example 
of a traffic management table that is a part of the data 
which the network resource management system 500 
holds. As shown in FIG. 59, a management ID, an IP 
address of management entity, the maximum circuit us- 
age efficiency, and a threshold of the maximum circuit 
usage efficiency are registered in the traffic manage- 
ment table for every management object entity con- 
tained in the network. 

[0150] FIG. 60 is a table showing a specific example 
of a user contract database (DB) that is a part of the data 
which the network resource management system 500 
holds. As shown in FIG. 60, the NAI, a contract service 
class, a service class actually used, and a status are 
registered in the user contract database for every user 
of the MN 600 connected to the network. 
[0151] FIG. 61 is a flowchart showing the operation of 
a service customizing process in the network resource 
management system 500. The service customizing 
process will be described below using this flowchart. 
[0152] The network resource management system 
500 checks the message type (step S700). If a custom- 
ize request message is determined, the user contract 
database as shown in FIG. 60 is checked (step S701). 
Then a check is made to see whether or not the user 
NAI exists (step S702). If the user NAI does not exist, 
the network resource management system 500 sends 
back a service customize response notifying the abnor- 
mal end (step S703). 

[0153] On the other hand, if the user NAI exists, the 
network resource management system 500 checks the 
traffic management table as shown in FIG. 59 (step 
S704). Then, a determination is made whether or not 



there is any entity having the maximum circuit usage ef- 
ficiency beyond the threshold (step S705). If such an 
entity exists, the network resource management system 
500 sends back a service customize response to notify 
that the customize request is rejected (step S706). If 
such entity does not exist, the network resource man- 
agement system 500 updates the user contract data- 
base (step S707), and sends back a service customize 
response to notify that the customize request is accept- 
ed (step S708). 

[0154] In the case where the received message type 
is a service change answer, the network resource man- 
agement system 500 updates the user contract data- 
base (step S710). 

[01 55] FIG. 62 is a flowchart showing the operation of 
a traffic supervising process in the network resource 
management system 500. A service change process 
under supervision of the network resource management 
system 500 will be described below using this flowchart. 
[0156] The network resource management system 
500 checks the maximum circuit usage efficiency (step 
S800).Then a determination is made whether or not the 
maximum circuit usage efficiency exceeds the threshold 
(step S801). If so, the network resource management 
system 500 checks the user contract database (step 
S802). Then a determination is made whether or not any 
class beyond the contract is used (step S803). In the 
case where the class beyond the contract is being used, 
a service change request notifying that the class of the 
user is lowered is transmitted to the AAAH 130 (step 
S804). 

[0157] The configuration and operation of each entity 
contained in the mobile IP network of this embodiment 
are the same as described above. Then some specific 
examples in which the service contents are changed ac- 
cording to the user's volition will be described below with 
reference to representative examples. 

1 . Procedure in the case where the user changes the 
service within the range of contract service class 

[01 58] FIG. 63 is a diagram showing the sequence for 
the user to change the service within the range of con- 
tract service class. In FIG. 63, the number given in pa- 
rentheses [ ] indicates the sequential number of com- 
munication procedure, and the communication proce- 
dure will be described below in accordance with this se- 
quential number. 

[1 ] The user gains access to the AAAH 1 30 through 
the WUI to make reference or change of the SPDB 
within the AAAH 130 

1 ) The user displays a main screen for service 
change as shown in FIG. 67 in accordance with 
a predetermined WUI process flow as shown in 
FIGS. 64 and 65. 

2) The user enters the NAI and the SPI of the 
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MN 600 at the predetermined positions of this 
main screen, and clicks on a "TO SERVICE 
CHANGE SCREEN" button. 

3) The AAAH 1 30 retrieves the SPDB as shown 

in FIG. 51 with the NAI and the SPI entered by 5 
the user as the retrieval key, and makes a check 
of whether or not there is any entry of the SPDB 
having the NAI and the SPI matched. If there is 
no entry matched, the error information is dis- 
played on the browser screen of the MN 600. 10 

4) On the other hand, in the case where there 
is an entry of the SPDB having the NAI and the 
SPI matched, the AAAH 1 30 retrieves a service 
class table as shown in FIG. 52 with the service 
class as the retrieval key, and extracts a corre- 15 
sponding entry from among the applicable 
services as shown in FIGS. 53 and 54. 

5) Then the AAAH 130 specifies a service 
which is set to be applicable (or turned on), ed- 
its the present service profile corresponding to 20 
this service or the selectable class information, 
using the service proper information as shown 

in FIGS. 55 and 56, and displays the contents 
of the service on the browser screen of the MN 
600 (FIG. 69). 25 

6) Then the user chooses a desired class, and 
clicks on an "APPLICATION" button on the 
browser screen. 

7) If the class chosen by the user is outside the 
range of contract service class, the operation 30 
transfers to a negotiation phase between the 
AAAH 130 and the network resource manage- 
ment system 500. On the other hand, if the 
class chosen by the user is within the range of 
contract service class, the AAAH 130 resets a 35 
user request to the SPDB. 

8) The AAAH 130 displays an error indication 
on the browser screen of the MN 600 (FIG. 71 ) 
if the SPDB resetting is not normally ended, or 
displays a registration success screen (FIG. 40 
70) if it is normally ended. Also, the AAAH 1 30 
automatically accesses an MIP client function 
(MCF) within the MN 600 to call an MIP regis- 
tration request process. 

45 

[2] The MN 600 creates an MIP registration request 
message for initial location registration in accord- 
ance with the operation procedure as shown in FIG. 
45, and sends it to the FA 41 0. 
[3] The FA 41 0 performs a predetermined process- so 
ing corresponding to the received MIP registration 
request message in accordance with the operation 
procedure as shown in FIG. 31 and sends an AMR 
message to the AAAF 430. 

[4] The AAAF 430 performs a predetermined 55 
processing corresponding to the received AMR 
message in accordance with the operation proce- 
dure as shown in FIG. 48, and forwards the AMR 



message to the AAAH 130. 
[5] The AAAH 1 30 performs an AMR checking proc- 
ess and an SPC creating process as follows in ac- 
cordance with the operation procedure as shown in 
FIG. 57. 

1) First of all, the AAAH 130 receives the AMR 
message, and then extracts the NAI of the user 
that is set in the user name AVP, and retrieves 
a table designated by a network part name with 
the NAI as the retrieval key to index the SPI of 
the user. 

2) If the SPI is retrieved, the AAAH 130 com- 
pares it with the SPI set in the MN-AAA-SPI 
AVP. If the comparison result is unmatched, an 
AMA message containing an error code is cre- 
ated and sent to the AAAF 430. 

3) If the comparison result is matched, the 
AAAH 1 30 retrieves a service class table with 
the service class as the retrieval key and ex- 
tracts an applicable service. 

4) The AAAH 130 creates an SPC correspond- 
ing to the service that is turned ON . In the case 
of the band control service, the SPC is created 
by referring to the service proper information 
such as the applicable QoS class. 

5) The AAAH 130 creates an HAR message 
containing the created SPC and sends it to the 
HA 110. 

[6] The HA 110 transmits an MIP binding update 
message to the CN 320 with reference to the CN 
list as shown in FIG. 33 and in accordance with the 
operation procedure as shown in FIGS. 35 and 36. 
[7] The CN 320 performs an SPC setting process in 
accordance with the operation procedure as shown 
in FIG. 40 and sends a binding acknowledge mes- 
sage to the HA 110. 

[8] The HA 110 sends an HAA message to the 
AAAH 130 in accordance with the operation proce- 
dure as shown in FIG. 36. 

[9] The AAAH 1 30 sends an AMA message to the 
AAAF 430 in accordance with the operation proce- 
dure as shown in FIG. 57. 

[1 0] The AAAF 430 sends the AMA message to the 
FA 410 in accordance with the operation procedure 
as shown in FIG. 48. 

[11] The FA 410 sends an MIP registration request 
message to the MN 600 in accordance with the op- 
eration procedure as shown in FIG. 31 . 
[12] The MN 600 performs an SPC reference proc- 
ess in accordance with the operation procedure as 
shown in FIG. 43. 

[0159] FIG. 66 is a table showing a list of screens to 
be displayed in the WUI process as shown in FIGS . 64 
and 65. In the WUI process, a main screen, a service 
reference screen, a service change screen, a registra- 
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tion success screen, an error screen, an ISP authenti- 
cation screen, or an initial start screen for the user, as 
shown in FIG. 66, is displayed as the browser screen 
for the MN 600 at a predetermined timing to the user. 
FIGS. 67 to 73 are views showing the display examples 
of these screens. The"ID" as shown in FIG. 66 indicates 
the display timing in the flowchart as shown in FIGS. 64 
and 65. At a step attached with each ID in the flowchart, 
a corresponding screen is displayed. 
[0160] In this way, in the mobile IP network of this em- 
bodiment, the content of SPC which the HA 110 or the 
AAAH 130 possesses can be updated by sending an 
MIP registration request message from the MN 600. In 
the case where there is an idle network resource, the 
network resources can be effectively utilized in accord- 
ance with a request from the user. Also, when an MIP 
registration request message is sent from the MN 600, 
the SPC of the apparatus involving the communication 
between the MN 600 and the CN 320 is only updated. 
Hence, it is possible to suppress the apparatuses to be 
updated to a minimum, thereby simplifying the proce- 
dure required for updating the SPC and reducing the 
costs for this updating process. 
[0161] In the case where a small number of packets 
are transmitted or received in practice even within the 
range of user contract service class, an extra network 
resource can be released in accordance with the actual 
amount of communication, enabling the effective use of 
network resources. 

[0162] The HA 1 1 0 is provided with a CN list contain- 
ing the addresses of the CN 320 to communicate with 
the MN 600, whereby the SPC within the CN 320 is up- 
dated on the basis of this CN list. Accordingly, the con- 
tents of the SPC stored in all the CNs 320 possibly com- 
municating with the MN 600 can be updated securely. 
When a packet is transmitted from each CN 320 to the 
MN 600, the service control on the basis of the service 
contents after change is enabled from the beginning. 
And since the content of this CN list is updated dynam- 
ically corresponding to a newly added CN 320, the MN 
600 can communicate with this newly added CN 320 on 
the basis of a new service content after update. 

2. Procedure in the case where the user changes the 
service outside the range of contract service class 

[0163] FIG. 74 is a diagram showing the sequence for 
the user to change the service outside the range of con- 
tract service class. 

[1 ] The user gains access to the AAAH 1 30 through 
the WUI to make reference or change of the SPDB 
within the AAAH 130. 

1 ) The user displays a main screen for service 
change as shown in FIG. 69 in accordance with 
a predetermined WUI process flow as shown in 
FIGS. 64 and 65. 



2) The user enters the NAI and the SPI of the 
MN 600 at the predetermined positions of this 
main screen, and clicks on a "TO SERVICE 
CHANGE SCREEN" button. 

5 3) The AAAH 1 30 retrieves the SPDB as shown 

in FIG. 51 with the NAI and the SPI entered by 
the user as the retrieval key, and makes a check 
of whether or not there is any entry of the SPDB 
having the NAI and the SPI matched. If there is 

10 no entry matched, the error information is dis- 

played on the browser screen of the MN 600. 

4) On the other hand, in the case where there 
is an entry of the SPDB having the NAI and the 
SPI matched, the AAAH 130 retrieves a service 

15 class table as shown in FIG. 52 with the service 

class as the retrieval key, and extracts a corre- 
sponding entry from among the applicable 
services as shown in FIGS. 53 and 54. 

5) Then the AAAH 130 specifies a service 
20 which is set to be applicable (or turned on), ed- 
its the present service profile corresponding to 
this service or the selectable class information, 
using the service proper information as shown 
in FIGS. 55 and 56, and displays the contents 

25 of the service on the browser screen of the MN 

600 (FIG. 68). 

6) Then the user chooses a desired class, and 
clicks on an "APPLICATION" button on the 
browser screen. 

30 7) If the class chosen by the user is outside the 

range of contract service class, the AAAH 130 
enters a negotiation phase between the AAAH 
130 and the network resource (NR) manage- 
ment system 500. 

35 

[2] The AAAH 130 makes a customize request to 
the network resource management system 500. 
The available interfaces may include COPS and 
CLI. 

40 [3] The network resource management system 500 
checks the user contract class and the network re- 
source situation in accordance with the operation 
procedure as shown in FIG. 61 , and sends back a 
service customize response to the AAAH 130. 

45 [4] The AAAH 1 30 performs the following process- 
ing in accordance with the customize response 
transmitted from the network resource manage- 
ment system 500. 

50 1 ) When the content of customize response is 

a normal reception, the AAAH 130 resets the 
content of user's request to the SPDB. 
2) When the content of customize response is 
a rejection, or the resetting of SPDB is not nor- 

55 mally made, the AAAH 130 displays an error 

screen as the browser screen of the MN 600 
(FIG. 71 ). Also, when the content of customize 
response is a normal reception, the AAAH 130 
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displays a registration success screen (FIG. 
70) as the browser screen of the MN 600, and 
further automatically accesses an MIP client 
function (MCF) of the MN 600 to request the 
transmission of an MIP registration request 5 
message. 

[5] The MN 600 creates an MIP registration request 
message for initial location registration in accord- 
ance with the operation procedure as shown in FIG. 10 
45, and sends it to the FA 41 0. 
[6] The FA 410 performs a predetermined process- 
ing corresponding to the received MIP registration 
request message in accordance with the operation 
procedure as shown in FIG. 31 . 15 
[7] The AAAF 430 performs a predetermined 
processing corresponding to the received AMR 
message in accordance with the operation proce- 
dure as shown in FIG. 48. 

[8]The AAAH 1 30 performs an AMR checking proc- 20 
ess and an SPC creating process as follows in ac- 
cordance with the operation procedure as shown in 
FIG. 57. 

1) First of all, the AAAH 130 receives an AMR 25 
message, then extracts the NAI of the user that 

is set in the user name AVP, and retrieves a ta- 
ble designated by a network part name with the 
NAI as the retrieval key to index the SPI of the 
user. 30 

2) If the retrieval of the SPI is ended, the AAAH 
130 compares this retrieved SPI with the SPI 
set in the MN-AAA-SPI AVP. If the comparison 
result is unmatched, an AMA message contain- 
ing an error code is created and sent to the 35 
AAAF 430. 

3) If the comparison result is matched, the 
AAAH 1 30 retrieves a service class table with 
the service class as the retrieval key and ex- 
tracts an applicable service. 40 

4) The AAAH 130 creates an SPC correspond- 
ing to the service that is turned ON. In the case 
of the band control service, the SPC is created 
by referring to the service proper information 
such as the applicable QoS class. 45 

5) The AAAH 130 creates an HAR message 
containing the created SPC and sends it to the 
HA 110. 

[9] The HA 110 transmits an MIP binding update so 
message to the CN 320 with reference to the CN 
list and in accordance with the operation procedure 
as shown in FIGS. 35 and 36. 
[10]The CN 320 performs an SPC setting process 
in accordance with the operation procedure as 55 
shown in FIG. 40. 

[11]The HA 110 sends an HAA message to the 
AAAH 130 in accordance with the operation proce- 



dure as shown in FIGS. 35 and 36. 
[12] The AAAH 130 sends an AMA message to the 
AAAF 430 in accordance with the operation proce- 
dure as shown in FIG. 57. 

[1 3]The AAAF 430 sends the AMA message to the 
FA in accordance with the operation procedure as 
shown in FIG. 48. 

[14] The FA 410 sends an MIP registration reply 
message to the MN 600 in accordance with the op- 
eration procedure as shown in FIG. 31. 
[15] The MN 600 performs an SPC reference proc- 
ess in accordance with the operation procedure as 
shown in FIG. 43. 

[01 64] In this way, in the case where the user changes 
the service content outside the range of contract service 
class, a negotiation is effected between the AAAH 130 
and the network resource management system 500. 
Therefore, the service content can be changed beyond 
the contract range in accordance with the idle situation 
of the network resources, enabling the effective use of 
all the network resources. At this time, the MN 600 is 
enabled to effect an initial location registration proce- 
dure (transmission process of an MIP registration re- 
quest message) with the change of content in the SPDB 
possessed by the AAAH 130 as a moment, so that the 
service contents can be set or changed, appropriating 
the initial location registration procedure performed by 
the MN 600. 

3. Procedure in the case where the user service is 
changed in accordance with a request from the network 
resource management system 500 

[0165] FIG. 75 is a diagram showing the sequence of 
changing the service within the range of user's contract 
service class upon a request from the network resource 
(NR) management system 500. 

[1 ] The network resource management system 500 
notifies a service change request to the AAAH 130 
in accordance with the operation procedure as 
shown in FIG. 62, and depending on a remaining 
situation of network resources. 
[2] The AAAH 1 30 recreates an SPC in accordance 
with the operation procedure as shown in FIGS. 57 
and 58, and sends an SCR message to the HA 1 1 0. 
[3] The HA 110 sends out an MIP binding update 
message to the CN 320 in accordance with the op- 
eration procedure as shown in FIGS. 35 and 36 and 
with reference to the CN list. 
[4]The CN 320 sends back a binding acknowledge 
message to the HA 110 in accordance with the op- 
eration procedure as shown in FIG. 40, only if the 
"A" bit is ON. 

[5] The HA 1 1 0 sends back an HAA message to the 
AAAH 130 in accordance with the operation proce- 
dure as shown in FIGS. 35 and 36. 
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[6] The AAAH 130 sends out an SCR message to 
the AAAF 430 in accordance with the operation pro- 
cedure as shown in FIG. 58. 
[7] The AAAF 430 sends out the SCR message to 
the FA 41 0 in accordance with the operation proce- 
dure as shown in FIG. 48. 
[8] The FA 41 0 sends back an SCA message to the 
AAAF 430 in accordance with the operation proce- 
dure as shown in FIG. 31. 

[9] The AAAF 430 sends back the SCA message to 
the AAAH 1 30 in accordance with the operation pro- 
cedure as shown in FIG. 48. 
[10] The AAAH 130 notifies a service change an- 
swer message to the network resource manage- 
ment system 500 in accordance with the operation 
procedure as shown in FIGS. 57 and 58. 
[11] The network resource management system 
500 updates a user contract DB in accordance with 
the operation procedure as shown in FIG. 61. 

[0166] In this way, since the service content can be 
changed upon a request from the network resource 
management system 500, the contents of network re- 
source available to the user can be set depending on 
the use conditions of the network resources, enabling 
the effective use of network resources. 

4. Procedure in the case where the SPC and the binding 
cache are reset in accordance with the CN list when the 
MN 600 is at hand-off 

[0167] FIG. 76 is a diagram showing the sequence for 
the user to change the service within the contract serv- 
ice class in an initial registration phase process which 
is performed when the foreign network to be connected 
is changed as the MN 600 is moved. 

[1] The MN 600 creates an MIP registration request 
message for initial location registration in accord- 
ance with the operation procedure as shown in FIG. 
45, and sends it to the FA 41 0. 
[2] The FA 410 performs a predetermined process- 
ing corresponding to the received MIP registration 
request message in accordance with the operation 
procedure as shown in FIG. 31 . 
[3]The AAAF 430 performs a predetermined 
processing corresponding to the received AMR 
message in accordance with the operation proce- 
dure as shown in FIG. 48. 

[4] The AAAH 1 30 performs an AMR checking proc- 
ess and an SPC creating process as follows in ac- 
cordance with the operation procedure as shown in 
FIG. 57. 

1) The AAAH 130 receives an AMR message, 
then extracts the NAI of the user that is set in 
the user name AVP, and retrieves a table des- 
ignated by a network part name with the NAI as 
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the retrieval key to index the S PI, service class. 

2) If the retrieval of the SPI is ended, the AAAH 
130 compares this retrieved SPI with the SPI 
set in the MN-AAA-SPI AVP. If the comparison 

5 result is unmatched, an AMA message contain- 

ing an error code is created and sent back to 
the AAAF 430. 

3) If the comparison result is matched, the 
AAAH 1 30 retrieves a service class table with 

10 the service class as the retrieval key and ex- 

tracts an applicable service. 

4) The AAAH 1 30 creates an SPC correspond- 
ing to the service that is turned ON. In the case 
of the band control service, the SPC is created 

15 by referring to the service proper information 

such as the applicable QoS class. 

5) The AAAH 130 creates an HAR message 
containing the created SPC and sends it to the 
HA 110. 

20 

[5] The HA 110 transmits an MIP binding update 
message to the CN 320 with reference to the CN 
list and in accordance with the operation procedure 
as shown in FIGS. 35 and 36. 

25 [6] The CN 320 performs an SPC setting process, 
as well as setting the binding cache, in accordance 
with the operation procedure as shown in FIG. 40. 
[7]The HA 1 1 0 sends an H AA message to the AAAH 
130 in accordance with the operation procedure as 

30 shown in FIG. 36. 

[8] The AAAH 130 sends an AMA message to the 
AAAF 430 in accordance with the operation proce- 
dure as shown in FIG. 57. 

[9] The AAAF 430 sends the AMA message to the 
35 FA 41 0 in accordance with the operation procedure 
as shown in FIG. 48. 

[10] The FA 410 sends an MIP registration reply 
message to the MN 600 in accordance with the op- 
eration procedure as shown in FIG. 31 . 
40 [1 1 ] The MN 600 performs an SPC reference proc- 
ess in accordance with the operation procedure as 
shown in FIG. 43. 

[0168] In this way, in the initial registration phase, the 
45 binding cache indicating the communication path to the 
CN 320 that is a communication destination of the MN 
600 is set in the CN 320. Hence, when the packet is 
transmitted from the CN 320 to the MN 600, the latest 
service contents can be reflected. 

50 

Claims 

1. A mobile network system comprising a home net- 
55 worktowhichmobileterminal equipment userssub- 
scribe, and a foreign network other than the home 
network, and a network management system for 
making a resource management of the whole net- 
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work and which is connected to said home network, 
said home network having: 

a home agent apparatus having a home ad- 
dress corresponding to said mobile terminal 5 
equipment and relaying a packet transmitted 
from a correspondent node to said mobile ter- 
minal equipment; and 

a home server apparatus for managing an au- 
thentication, authorization and accounting con- 10 
cerning said home network; 
said foreign network having: 

a foreign agent apparatus for relaying said 
packet transferred from said home agent is 
apparatus to said mobile terminal equip- 
ment; and 

a foreign server apparatus for managing 
the authentication, authorization and ac- 
counting concerning said foreign network; 20 
wherein by transmitting a registration re- 
quest message containing service content 
changing information from said mobile ter- 
minal equipment to said foreign agent ap- 
paratus, service control information con- 25 
cerning said mobile terminal equipment 
which is possessed by each of said foreign 
agent apparatus, said foreign server appa- 
ratus, said home server apparatus, said 
home agent apparatus and said corre- 30 
spondent node which exist on a communi- 
cation path between said mobile terminal 
equipment and said correspondent node is 
updated. 

35 

2. A mobile network system comprising a home net- 
work to which mobile terminal equipment users sub- 
scribe, and a foreign network other than the home 
network, and a network management system for 
making a resource management of the whole net- 40 
work and which is connected to said home network, 
said home network having: 

a home agent apparatus having a home ad- 
dress corresponding to said mobile terminal 45 
equipment and relaying a packet transmitted 
from a correspondent node to said mobile ter- 
minal equipment; and 

a home server apparatus for managing an au- 
thentication , authorization and accounting con- so 
cerning said home network; 
said foreign network having: 

a foreign agent apparatus for relaying the 
packet transferred from said home agent 55 
apparatus to said mobile terminal equip- 
ment; and 

a foreign server apparatus for managing 



the authentication, authorization and ac- 
counting concerning said foreign network; 
wherein by making a request of changing 
a service content from said network man- 
agement system to said home server ap- 
paratus, service control information con- 
cerning said mobile terminal equipment 
which is possessed by each of said foreign 
agent apparatus, said foreign server appa- 
ratus, said home server apparatus, said 
home agent apparatus and said corre- 
spondent node which exist on a communi- 
cation path between said mobile terminal 
equipment and said correspondent node is 
updated. 

3. The mobile network system according to claim 1 , 
wherein said home server apparatus has an access 
right to a service information database for storing 
the present service content information for every 
mobile terminal equipment, and when the registra- 
tion request message is transmitted from said mo- 
bile terminal equipment, the service content infor- 
mation stored in said service information database 
is changed within a range of service contents stip- 
ulated by contract for said mobile terminal equip- 
ment. 

4. The mobile network system according to claim 1 , 
wherein said home server apparatus has an access 
right to a service information database for storing 
the present service content information for every 
mobile terminal equipment, and when the registra- 
tion request message is transmitted from said mo- 
bile terminal equipment, a negotiation is made with 
said network management system, if the service 
content information to be changed exceeds the 
range of service contents stipulated by contract for 
said mobile terminal equipment. 

5. The mobile network system according to claim 3, 
wherein said home server apparatus enables said- 
mobile terminal equipment to effect an initial loca- 
tion registration procedure with the aim at changing 
the service control information at a moment when 
the service content information stored in said serv- 
ice information database is changed. 

6. The mobile network system according to claim 5, 
wherein upon receiving a predetermined message 
corresponding to said initial location registration 
procedure, said home server apparatus updates 
the service control information that is possessed by 
each of said foreign agent apparatus, said foreign 
server apparatus, said home server apparatus, said 
home agent apparatus, and said correspondent 
node which are present on the communication path 
between said mobile terminal equipment and said 
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correspondent node on the basis of the service con- 
tent information after change that is stored in said 
service information database. 

7. The mobile network system according to claim 6, 5 
wherein said home agent apparatus has a list of ad- 
dresses for the correspondent nodes that become 

a communication partner, and said home server ap- 
paratus updates the service control information for 
one or more correspondent nodes contained in this 10 
list. 

8. The mobile network system according to claim 7, 
wherein said home agent apparatus adds the ad- 
dress of a correspondent node that has newly com- is 
municated with said mobile terminal equipment to 
said list dynamically, and sets the service control 
information to the newly added correspondent 
node. 

20 

9. The mobile network system according to claim 1 , 
wherein said home agent apparatus has a list of ad- 
dresses for the correspondent nodes that become 
a communication partner, and said home server ap- 
paratus sets binding cache information indicating a 25 
connecting state between said mobile terminal 
equipment and said home agent apparatus to said 
correspondent nodes contained in said list, in an in- 
itial registration phase process of said mobile ter- 
minal equipment. 30 

10. The mobile network system according to claim 9, 
wherein said home agent apparatus instructs all the 
correspondent nodes contained in said list to reset 
the binding cache information, when said foreign 35 
network to which said mobile terminal equipment is 
connected is changed. 

11. The mobile network system according to claim 7, 
wherein said home agent apparatus deletes the un- 40 
necessary addresses of said correspondent nodes 
from said list by performing an aging process. 

12. The mobile network system according to claim 9, 
wherein said home agent apparatus deletes the un- 45 
necessary addresses of said correspondent nodes 
from said list by performing an aging process. 

13. The mobile network system according to claim 7, 
wherein a predetermined response message to be so 
transmitted when the processing in said corre- 
spondent nodes contained in said list is ended to 
said home agent apparatus is omitted. 

14. The mobile network system according to claim 9, 55 
wherein a predetermined response message to be 
transmitted when the processing in said corre- 
spondent nodes contained in said list is ended to 



530 A2 




said home agent apparatus is omitted. 

15. The mobile network system according to claim 1 , 
wherein said mobile terminal equipment allows ref- 
erence by indication to the content of the service 
control information set for each mobile terminal 
equipment on the basis of a registration response 
message transmitted from said foreign agent in cor- 
respondence to said registration request message. 

1 6. Amethod for changing service control information in 
amobile network, comprising the steps of: 

changing the service control information of a 
user that is managed in a home network to 
which the user of the mobile terminal equip- 
ment subscribes when the mobile terminal 
equipment is present in a foreign network other 
than said home network; 
transmitting a registration request message to 
said home network, after changing said service 
control information; 

transmitting the service control information af- 
ter change from said home network having re- 
ceived said registration request message to 
said foreign network where said mobile termi- 
nal equipment is present; and 
receiving a service based on said service con- 
trol information after change at said mobile ter- 
minal equipment in said foreign network. 
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\ TYPE? / 
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RETRIEVE SESSION 
TRANSACTION 
WITH USER NAI 



SET SPC IN 
SESSION 
TRANSACTION 
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FORWARD 
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(start) 



S600 



MESSAGE 
TYPE? 



{ 



> 



HAA 



AMR 
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WHETHER OR NOT \ Y pc: 
SESSION TRANSACTION^ 2 
EXIST? 

si 



NO 



:02 



CREATE NEW 

SESSION 
TRANSACTION 



S603 



RETRIEVE SPDBWITH USER NAI, 
AND CREATE SPC ON BASIS OF 
RETRIEVED INFORMATION 



SET SPC IN 
SESSION 
TRANSACTION 



i 



-S604 



S605 



WHETHER OR NOT \ 
MN-SPC AVP EXIST I N, 
AMR? / 



NO 



YES 



S606 



RETRIEVE USER SERVICE 
INFORMATION WITHIN SPDB 
WITH USER NAI, AND CREATE 
SPC ON BASIS OF 
RETRIEVED RESULT 



S607 



TRANSMIT HAR 

CONTAINING 
CREATED SPC 
TO HA 



S61 O 



TRANSMIT AMA 
CONTAINING SPC 
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( END ) 
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(START) 
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REQUEST 
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SEND BACK 
SERVICE 
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NOTIFY THAT 

CUSTOMIZE 
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( END ) 
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SEND BACK 
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RESPONSE TO 
NOTIFY THAT 
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REJECTED 
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SEND BACK 
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RESPONSE TO 
NOTIFY THAT 
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(start) 
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